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Abstract 
This document describes the high-level requirements for Internet 


Voice Mail (IVM) and establishes a baseline of desired functionality 
against which proposed MIME profiles for Internet Voice Messaging can 


be judged. IVM is an extension of the Voice Profile for Internet 
Mail (VPIM) version 2 designed to support interoperability with 
desktop clients. Other goals for this version of VPIM include 


expanded interoperability with unified messaging systems, conformance 
to Internet standards, and backward compatibility with voice 
messaging systems currently running in a VPIM enabled environment. 
This document does not include goals that were met fully by VPIM 
version 2. 


1. Introduction 


Until recently, voice mail and call answering services were 
implemented as stand-alone proprietary systems. Today, standards 
such as the Voice Profile for Internet Mail (VPIM) enable 
interoperability between such systems over the Internet. VPIM 
version 1 [VPIM1] was experimental and was a first attempt at a Voice 
Profile for Internet Mail, but is now classified as Historical.  VPIM 
Version 2 [VPIM2] is an improvement on VPIM version 1 that was 
originally intended to provide interoperability between voice 
messaging systems only. It describes a messaging profile that 
standardizes the exchange of voice mail over an IP messaging network 
using SMTP [DRUMSMTP] and MIME [MIME1]. 


Because the number of desktop boxes is growing rapidly and will soon 
approach the number of desktop telephones, it is essential to 
consider the requirements of desktop email client applications 
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(including, but not limited to, MIME-compliant email clients). With 
the trend toward integration of voice mail and email through unified 
messaging (UM), it is now necessary to define a profile that supports 
the needs of desktop applications and unified messaging systems 
(including Internet Facsimile [EXFAX]). This profile is being 
referred to as Internet Voice Mail (IVM). 


This document defines the goals for Internet Voice Mail. This 
standard will support the interchange of voice messages between voice 
mail systems, unified messaging systems, email servers, and desktop 
client applications. The desktop client application is of particular 
and important interest to IVM. This document will also expand the 
offerings of service providers by facilitating access to voice mail 
from a web client. 


2. Conventions used in this document 


The following terms have specific meaning in this document: 


"service" An operational service offered by a service provider 
"application" A use of systems to perform a particular function 
"terminal" The endpoint of a communication application 

"goal" An objective of the standardization process 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[RFC2119]. 


3. Goals for Internet Voice Mail 
3.1. Interoperability 


Enhanced interoperability is the primary goal of IVM. The profile 
MUST facilitate interoperability between voice mail systems, unified 
messaging systems, Internet email servers, and desktop client 
applications. Such interoperability MUST support systems which 
combine multiple media types in a single message, as well as legacy 


voice mail and email systems. It MUST allow the ability to 
accommodate varying capabilities of the voice mail, unified 
messaging, and email systems. Furthermore, IVM MUST be compatible 


with Internet Fax (extended mode) proposed standards and VPIM 
messages that contain fax body parts. 
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To have "interoperability" means that an IVM compliant sender 
attempting to send to a recipient will not fail because of 
incompatibility. IVM MUST support interoperability amongst the 
systems listed below: 


- Desktop Email client applications 

- IVM-capable Voice Mail systems 

- IVM-capable unified messaging systems 
— Traditional email servers 


IVM SHOULD also support interoperability with VPIM version 2 Voice 
Mail Systems. 


IVM MUST include new functionality to facilitate access to voice mail 
messages from desktop applications. 


Overall interoperability requires interoperability for all message 
elements: body parts deemed essential for message validity MUST be 
preserved, essential information MUST be provided in a form that is 
accessible by the users, status codes [CODES] MUST be understood, and 
operations that are standard for each system SHOULD be supported. 


3.1.1. Interoperability with Desktop Email Client Applications 


Desktop email applications are typically text based. The abilities 
to listen to, reply to, forward, and generate voice mail messages 
from a traditional desktop environment are relatively new 
developments. To accommodate current use and future developments in 
this area, IVM MUST provide features to support access to voice mail 
messages from the desktop and other email-reading devices. Also, web 
access to voicemail SHOULD be supported from the desktop. 


IVM SHOULD NOT require desktop email applications to possess a large 
amount of processing power, and a base level implementation MUST 
interoperate, even if it does not offer complex processing. In order 
to support interoperability, at least one mandatory codec MUST be 
defined. The mandatory codec(s) SHOULD be widely available on 
desktops. For interoperability with VPIM version 2 systems, IVM 
applications MAY also support the VPIM v2 mandatory codec, 32KADPCM 
[ADPCM and G726-32]. 


Any codecs included in the IVM specification SHOULD meet the 
following criteria: 


- Availability on desktops: Codecs SHOULD be available on most 
platforms. 
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- Source code availability: Source code SHOULD be readily 
accessible. 


- Decoding complexity: All codecs MUST be low complexity to 
decode. 


- Encoding complexity: Some of the codecs MUST be low complexity 
to encode. 


- Bit rate: IVM SHOULD specify a codec with low bit rate for 
devices (i.e., wireless) that do not have much space/bandwidth. 


- Voice Over IP support: IVM SHOULD specify a codec that supports 
Voice over IP implementations. 


Voice Content MUST always be contained in an audio/basic content- 
type unless the originator is aware that the recipient can handle 
other content. To enable future support of other formats, IVM SHOULD 
provide identification of the codec used without requiring 
interpretation of an audio format. IVM MAY allow audio encodings and 
formats that are not identified in the IVM specification to support 
environments in which the sender is aware of the optimal encoding and 
format for the recipient. 


To address performance and bandwidth issues, IVM MAY support 
streaming of IVM audio to the desktop. IVM MAY explicitly support 
formats other than raw audio to facilitate streaming. 


Because most email readers are text/html based and because many 
devices are not capable of recording audio content, IVM MUST allow 
inclusion of text body parts in a voice message. IVM SHOULD NOT 
explicitly prohibit other media types as long as critical content is 
identified and minimal discard rules are specified. 


To support devices that have applications dedicated to specific media 
types or that are not capable of handling specific content, IVM 
SHOULD define a way to describe the content of the message, 
indicating how the content can be accessed. 


Desktop implementation of IVM MUST support attachments of any media 
type. 
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3.1.2. Interoperability with IVM-capable Voice Messaging Systems 


Voice messaging systems are generally implemented as special-purpose 
machines that interface to a telephone switch and provide call 
answering and voice messaging services. VPIM version 2 was designed 
to support interoperability between such systems and remains the best 
messaging profile for this purpose. 


To support interoperability between IVM voice messaging systems and 
other compliant systems, IVM SHOULD have a minimum set of required 
features that will guarantee interoperability, and also provision for 
additional functionality that may be supported by more complex 
systems. IVM MUST define a mechanism for identifying essential 
content and status codes [CODES] indicating that a message could not 
be delivered due to capability differences. 


NOTE: IVM SHOULD provide some level of interoperability with VPIM 
version 2 voice messaging systems. In order to support minimal 
interoperability between IVM and VPIM version 2, IVM systems MAY be 
able to receive the VPIM version 2 32KADPCM codec [ADPCM and G726- 
32], and MUST gracefully handle the case where a legacy receiving 
system does not support the IVM codecs. 


3.1.3. Interoperability with IVM-capable Unified Messaging Systems 


Unified messaging solutions typically leverage common store, 
directory, and transport layers to provide greater interoperability 
and accessibility to a variety of media content. They support 
creation of and access to voicemail, email, and fax messages from a 
single user interface. 


To accommodate the common functionality of unified messaging systems, 
IVM MUST support the inclusion of body parts containing different 
media types. It MUST also handle messages that contain VPIM messages 
as attachments to messages of another type (such as multipart/mixed), 
and VPIM messages that contain attachments of another type. 


To provide interoperability with systems that cannot handle a 
particular content type, IVM MUST provide a mechanism for identifying 
critical content and MAY define media specific status codes and 
strings to handle non-delivery of these body parts. 
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3.1.4. Interoperability with Traditional Email Servers 


Traditional email servers are those that support only textual media 
as inline content. IVM MUST interoperate consistently with the 
current Internet mail environment. If an IVM message arrives in 
users’ mailboxes, IVM MUST provide a mechanism to interoperate with 
common user practices for mail messages: storing them in databases, 
retransmission, forwarding, creation of mail digests, and replying to 
messages using non-audio equipment. 


3.2. Conformance to Existing Standards 


It is the goal of IVM to conform as closely as possible to existing 
standards while meeting the other goals defined in this document. 


- Restrictions: The profile SHOULD impose as few restrictions as 
possible to existing Internet mail standards. In particular, it 
MUST support all elements of RFC 2822 [DRUMSIMF], except those 
that prevent the profile from meeting other IVM goals. 


- Additions: The profile SHOULD make as few additions as possible to 
existing internet mail standards. It SHOULD adhere to existing 
desktop conventions in desktop-related areas such as file 
extensions. If it is necessary to define new MIME types or sub- 
types, the IVM work group SHOULD propose terms that are already 
standard or in common use in the desktop environment. 


3.3. Backward Compatibility 


This profile SHOULD provide backward compatibility with VPIM version 
2 to the extent that the functionality required to meet the goals of 
this profile is not compromised. Where backward compatibility is not 
possible, IVM SHOULD provide and define a minimal set of rules and 
status codes for handling non-delivery of IVM messages resulting from 
interoperability with VPIM version 2 systems and other legacy 
systems. 


3.4. Robustness 


IVM MUST be usable in an environment in which there exist legacy 
gateways that do not understand MIME. Core features and critical 
data MUST not be lost when messages pass through AMIS gateways 
[AMIS-A and AMIS-D]. IVM SHOULD allow interoperability with 
recipient devices and gateways that have limited buffering 
capabilities and cannot buffer all header information. 
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5. Security Considerations 


To facilitate security, IVM MUST support authenticated and/or 
encrypted voice messages. In addition, IVM MUST adhere to the 
security issues identified in VPIM v2 [VPIM2] and in the other RFCs 
referenced by this document, especially SMTP [DRUMSMTP], Internet 
Message Format [DRUMSIMF], and MIME [MIME1]. 
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